@bespaltovyj
I change access level and imrpove springfox compatible in this pr. But will this be bad, because I don't know the design of this project so well that the configuration I submit does not conform to the specification. I'm wondering if I should just keep the part that modifies the access level of the code so it can be merged faster.

@NaccOll sorry, but I am not involved in this project so deep

@bespaltovyj Sorry, I typed the wrong username due to autocompletion

@bnasslahsen
I change access level and imrpove springfox compatible in this pr. But will this be bad, because I don't know the design of this project so well that the configuration I submit does not conform to the specification. I'm wondering if I should just keep the part that modifies the access level of the code so it can be merged faster.

@NaccOll,

No problem for changing the access level if there a right justification.
Could you please add the related tests to your PR so we can understand why these changes are necessary ?

@bnasslahsen
I think we need to discuss the issue before adding test cases. As I said in the issue, springdoc's compatibility with springfox is not as good as the documentation says. More importantly, springdoc does not provide an out-of-the-box behavior consistent with spring mvc. For example, now springdoc treats query parameter objects as json or does not set parameters to form data when specifying api to accept form data. These default behaviors will cause developers to spend more time writing swagger annotations by themselves. In this pr, I did two things, one was to modify the access level of the code, and the other was to configure the three problems I said in the issue. When writing test cases for code access level, do I need to roll back the solution to the problem mentioned in the issue? It's embarrassing that modifying the code access level is to fix the default behavior bug. However, I also solved the latter in pr.

@bnasslahsen
In addition, I will talk about the detailed reasons why the code access level needs to be changed. The core code is in org.springdoc.core.AbstractRequestService#build, and in order to rewrite this method, I copy several methods org.springdoc.core.AbstractRequestService#getApiParameters, org .springdoc.core.AbstractRequestService#getParamJavadoc, org.springdoc.core.AbstractRequestService#getParameterLinkedHashMap, because they are private methods.

Then the build method calls org.springdoc.core.DelegatingMethodParameter#customize. I need to override this method. However, the constructor of DelegatingMethodParameter is visible to the package and I cannot inherit it, so I can only copy the code to implement org.springframework.core. MethodParameter.

Then I met

Can not set final [Ljava.lang.annotation.Annotation; field org.springdoc.core.DelegatingMethodParameter.additionalParameterAnnotations to io.naccoll.boilerplate.core.openapi.springdoc.core.CustomDelegatingMethodParameter

...
org.springdoc.core.customizers.DataRestDelegatingMethodParameterCustomizer.customize(DataRestDelegatingMethodParameterCustomizer.java:95)

The cause of this problem is that DelegatingMethodParameter#customize in org.springdoc.core.AbstractRequestService#build was modified by me to CustomDelegatingMethodParameter. Also, the access level of the MethodParameterPojoExtractor is package visible, which I copied again.

In order to solve the error of DataRestDelegatingMethodParameterCustomizer, I can only write CustomDataRestDelegatingMethodParameterCustomizer. Originally, I only need to rewrite the customize method. However, the access level of many other methods is private, and I can only copy it, just to modify one line of code.

The above are the classes that I need to rewrite in order to solve the problem of default behavior. However, in the process, I found that there is a possibility of rewriting, such as org.springdoc.core.RequestBodyService#calculateRequestBodyInfo, which involves org.springdoc.core.GenericParameterService, I also adjusted their access levels

@NaccOll,

I have taken in consideration your proposal in this commit fb42478
I didn't add the visibility change of methods and the properties as people can manage achieving it without these.

Thank again for your efforts to make the project adoption easier.

Do not hesistate, to propose additionnal to complete my actual commit. Just make sure the PRs do not mix a lot of changes.